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Abstract. This paper defines the notion of hybrid atomicity for nested trans- 
action systems, and presents and verifies an algorithm providing this prop- 
erty. Hybrid atomicity is a modular property; it allows the correctness of 
a system to be deduced from the fact that each object is implemented to 
have the property. It allows more concurrency than dynamic atomicity, by 
assigning timestamps to transactions at commit. The Avalon system provides 
exactly this facility. 
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1 Introduction 

Two-phase locking [4] is probably the most widely used method of concurrency con- 
trol in transaction systems today. In recent years much research has focused on ex- 
tending concurrency control methods to take the semantics of the data into account, 
thus permitting more concurrency by allowing transactions executing commuting 
operations to run concurrently (e.g., see [9, 14, 17, 16, 15]). Such "logical locking" 
can be important to avoid concurrency bottlenecks that arise at frequently updated 
data items (or "hot spots"). For some applications, however, the requirement that 
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non-commuting operations must conflict can hurt performance by restricting con- 
currency. Recently, Herlihy and Weihl proposed a new technique, based on assigning 
timestamps to transactions as they commit and propagating the timestamp infor- 
mation to objects, that allows some of the conflicts imposed by commutativity to be 
eliminated [7, 8]. In this paper we extend their algorithm to accommodate nested 
transactions, using the framework developed in [5]. Our results show the general- 
ity of the framework used here, and also point out the subtleties involved both in 
defining algorithms for nested transactions and in proving them correct. 

Locking algorithms serialize transactions dynamically in the order in which they 
commit. However, detailed information about the commit order is not usually avail- 
able to the concurrency control algorithm, particularly in a distributed system; in- 
stead, locking makes conservative assumptions about the commit order based on 
when locks are acquired and released. Thus, commutativity-based algorithms require 
an operation executed by a transaction to commute with all operations previously 
executed by other transactions that are still active; this ensures that regardless of 
the order in which they commit, their operations will be serializable in that order. 
As Herlihy and Weihl discuss, however, commutativity-based algorithms allow very 
little concurrency for some applications. For example, the enqueue and dequeue op- 
erations on a FIFO queue do not commute, so commutativity-based locking reduces 
to exclusive locking, preventing one transaction from accessing the queue until the 
previous one has committed. 

Herlihy and Weihl describe hybrid techniques that combine aspects of timestamp- 
based and locking algorithms. Their algorithm relies on timestamps generated as 
transactions commit to capture the commit order. Objects learn the exact commit 
order by being told the timestamps for committed transactions. As discussed in 
more detail below, this information can be used to relax the constraints imposed by 
commutativity-based locking by basing the conflict relations on serial dependency 
relations, rather than on commutativity. For example, the enqueue operations on a 
FIFO queue do not need to depend on each other, so transactions executing enqueue 
operations can be allowed to run concurrently. The apparent serialization order of 
the enqueues can be sorted out based on the timestamps generated when transac- 
tions commit, so the order of items in the queue can be determined for subsequent 
dequeues. 

In this paper, we show how Herlihy and Weihl's algorithm can be extended 
to accommodate nested transactions. Nested transactions have been explored in a 
number of projects (e.g., [13, 12, 10, 3, 1]) for building reliable distributed systems. 
In a nested transaction system, a transaction can have subtransactions, each of which 
appears to run atomically within the transaction. Thus, concurrent subtransactions 
are serializable — they appear to run in some serial order — and recoverable — they 
appear to execute either completely or not at all. In addition, if a subtransaction 
aborts, its parent is informed of the abort and can choose to try some alternative 
action (e.g., in a replicated system). 

We give a precise, formal description of the extended algorithm. We use the 
framework presented in [5] as a basis for this work. This framework provides a 
rigorous foundation for nested transaction systems based on a formal operational 
model. Nested transactions introduce a number of subtleties, concerning the precise 
handling of concurrent subtransactions and of aborts, that require a careful rigorous 



treatment. 

Our presentation parallels our earlier work on locking algorithms. We describe a 
system consisting of transactions plus objects, together with a controller that medi- 
ates communication between the transactions and the objects. We use the general 
definition of correctness from our previous work, and define a local property of ob- 
jects, called hybrid atomicity, that is sufficient to guarantee global correctness. 3 (I.e., 
if each object in a system is hybrid atomic, the system as a whole is correct.) Hybrid 
atomicity captures the property of an individual object that says that it serializes 
transactions in the commit order provided to the object by the timestamps gen- 
erated at commit. Then we show how to extend Herlihy and Weihl's algorithm to 
handle nested transactions; the resulting object is hybrid atomic. 

Introducing a local property such as hybrid atomicity affords important modu- 
larity. Each object can be implemented independently, and as long as each is hybrid 
atomic, the entire system will be correct. Simple concurrency control techniques 
(e.g., exclusive locking or read-write locking) can be used where the need for concur- 
rency is small, and more complex techniques (e.g., the algorithm described in this 
paper) can be used in the (usually few) cases where more concurrency is needed. 
Hybrid atomicity captures the properties of the interactions among objects that are 
essential for global correctness, in particular, how they agree on a serialization order 
for transactions. 

The Avalon system [3] (built on top of Camelot) has adopted hybrid atomicity 
for nested transactions as the basis of its operation. The tid or transaction iden- 
tifier generated by the system has a comparison operation that indicates which of 
two transactions committed first. This information is just what is needed by our 
algorithm, and thus our algorithm could be used in the Avalon system. 

The remainder of this paper is organized as follows. First, in Section 2 we define 
the model appropriate for a system assigning timestamps at commit time; we also 
define hybrid atomicity. In Section 3 we present an algorithm that is hybrid atomic. 
Finally, we conclude with a discussion and some suggestions for further work. In an 
Appendix, we briefly summarize the earlier work of ours that provides the framework 
for this paper. Because of length constraints, this paper omits all the proofs of our 
results. The proofs will appear in [6]. 

2 Hybrid Atomicity 

This section depends on our earlier work, presented as Sections 3 to 5 of [5], and 
summarized in the Appendix. The development in this section closely parallels that 
in Section 6 of [5] and also that in [2]. In our presentation we concentrate on those 
aspects that are different from the previous papers. 

We define the system decomposition appropriate for describing hybrid algo- 
rithms. Such algorithms are formulated as instances of hybrid systems, which are 
composed of transaction automata, hybrid object automata and a hybrid controller. 

Throughout, we use a totally ordered set V of timestamps. In our development, 
we will not actually need the set V to be totally ordered - it will be enough that the 



3 Weihl defined several local properties for single-level transaction systems [17, 16]; the 
local property defined here generalizes one of those to nested transaction systems. 



timestamps assigned to sibling transactions be ordered with respect to each other. 
However, for simplicity we assume the total ordering. A natural choice for V is the 
set of positive integers, or more realistically, the integers less than some (extremely 
large) maximum. 



Hybrid Object Automata A hybrid object automaton Hx for an object name 
X is an automaton with the following actions, which define its interface to its en- 
vironment. The input actions are CREATE(T), for T an access to X, INFORM- 
_COMMIT_AT(X)OF(7>),for T £ T ,pE T>, and INFORM_ABORT_AT(X)OF(T), 
for T ^ T . The output actions are REQUEST_COMMIT(7», for T an access 
to X and v a value for T. In addition, H x may have an arbitrary set of internal 
actions. 

The interface of a hybrid object automaton H x is similar to that of a generic ob- 
ject Gx, as defined in [5] to model data managers that receive requests for data access 
and information about the completion of transactions. It differs in that explicit times- 
tamp information is included in all INFORNLCOMMIT actions. It is also similar to 
that of a pseudotime object (as defined in [2]) in that the object receives timestamp 
information for some transactions. However, hybrid objects differ from pseudotime 
objects in that the timestamp information is included in the INFORM_COMMIT 
actions rather than in separate INFORM_TIME actions; thus, timestamp informa- 
tion only arrives for transactions that have committed. Also, hybrid objects receive 
timestamp information for arbitrary transactions, not just for accesses to X. 

A hybrid object automaton H x is required to preserve hybrid object well-formedness, 
defined to include all the constraints corresponding to those in the definition of 
generic object well-formedness in [5]. In addition, there are restrictions on the times- 
tamps supplied, similar to those in the definition of pseudotime object well-formedness 
in [2]: there is no transaction T for which there are two different timestamps, p 
and p', such that INFORM_COMMIT^AT(X)OF(7» and INFORM_COMMIT- 
_AT(X)OF(T,p') both occur in /?, and there is no timestamp p for which there are 
two different transactions, T and T', such that T and V are siblings and INFORM- 
_COMMIT_AT(X)OF(7» and INFORM_COMMIT^AT(X)OF(T y ,p) both oc- 
cur in /?. Notice that the same timestamp may be assigned to different transactions, 
so long as they are not siblings. 



Hybrid Controller The hybrid controller behaves much the same as the generic 
controller defined in [5]. The main difference is that, when it commits a transaction, 
it simultaneously assigns a timestamp to that transaction; subsequently, it passes 
that timestamp to the hybrid objects in INFORNLCOMMIT actions. The only 
constraint on the assignment of timestamps is that they get assigned to siblings in 
increasing order. 

The assignment of timestamps is somewhat different from the assignment of 
pseudotimes that occurs in the pseudotime controller of [2]. In a hybrid system, 
individual timestamps are assigned to transactions, whereas in a distributed pseu- 
dotime system, intervals of pseudotime are assigned. Also, in a hybrid system, the 
timestamp for a transaction is chosen when the transaction commits, whereas in a 



distributed pseudotirne system, the pseudotime interval for a transaction is chosen 
before the transaction starts executing. 

The hybrid controller we model is highly nondeterministic, in particular because 
each timestamp can be chosen arbitrarily, subject to the constraint that it is greater 
than the timestamps of all previously committed siblings. Actual implementations 
will restrict the nondeterminism by choosing timestamps in a controlled way. One 
simple method in a centralized system is to assign to each transaction the value of 
the clock at the instant the transaction commits. In this case, each transaction's 
timestamp is greater than that of all previously committed transactions, instead of 
merely the committed siblings as required. Another implementation can be obtained 
by assigning the timestamp i to a transaction if it is the i-th child of its parent that 
commits. 

The hybrid controller has in its interface the actions of the transaction automata 
and the hybrid object automata, as well as extra actions COMMIT and ABORT 
for each transaction other than T . The code of the hybrid controller is identical to 
that of the generic controller from [5], except that the COMMIT(T) action chooses 
a timestamp p and records it in the state, and the INFORM_COMMIT action 
includes the appropriate timestamp. 

Hybrid Systems A hybrid system is the composition of the hybrid controller, all 
the transaction automata (just as in the serial system), and a collection of hybrid 
object automata. The behaviors of a hybrid system are called hybrid behaviors. We 
have the following result: If /? is a hybrid behavior, then for every object name X, 
P\Hx is hybrid object well-formed for X. 

Hybrid Atomicity Now hybrid atomicity is defined. The definition is almost the 
same as the definition of dynamic atomicity in [5] but it is based on hybrid systems 
instead of generic systems. It is also similar to static atomicity defined in [2], but 
the order used is the completion order. 

Let Hx be a hybrid object automaton for object name X. Say that Hx is hybrid 
atomic if for all hybrid systems S in which Hx is associated with X, the following is 
true. Let be a finite behavior of S, R = completion^) and T a transaction name 
that is not an orphan in /?. 4 Then view(serial0), T, R, X) is a serial behavior of Sx • 
The following theorem is an direct consequence of Theorem 3. 

Theorem 1. (Hybrid Atomicity Theorem) Lei S be a hybrid system in which all 
hybrid objects are hybrid atomic. Let f3 be a finite behavior of S. Then (3 is serially 
correct for every non-orphan transaction name. 

Local Hybrid Atomicity We now give a local version of hybrid atomicity. The 
development is analogous to that for local dynamic atomicity in Section 6 of [5] 
(in that we define local analogues for many concepts) but includes some significant 
technical changes, needed to allow us to prove that the algorithm of Section 3 is 
correct. 

4 Recall that a transaction T is an orphan in /? if ABORT(£7) appears in fi for some 
ancestor U of T. 



We begin by defining local visibility and local- completion exactly as in [5]. That 
is, if H x is a hybrid object automaton for object name X, and /? is a sequence 
of external actions of H x , then T is locally visible at X to V in /3 if con- 
tains an INFORM_COMMIT_AT(X)OF(f/,p) event for every U in ancestors(T) - 
ancestors^), and local- compleiion(($) is the binary relation on accesses to X where 
(U, U f ) G local- completion^) if and only \tU ^ U 1 ', /? contains REQUEST_COMMIT 
events for both 17 and U\ and £/ is locally visible at X to [/' in /?', where /?' is the 
longest prefix of/? not containing the given REQUEST_COMMIT event for U* . 

In this paper we will use a different notion of local orphans from that in [5] 
and [2]. The prior definition designated a transaction T as a local orphan exactly 
if an INFORM_ABORT appears for an ancestor of T. The new definition includes 
additional conditions that imply that a transaction is an orphan. For example, it can 
be deduced that an access V to object X is an orphan provided that T" is created 
and that an INFORM_COMMIT event occurs for an ancestor of V without any 
preceding REQUEST-COMMIT for T'. Moreover, if such an access V is locally 
visible to any transaction T, then it can also be deduced that T is an orphan. 

More formally, if /? is a sequence of external actions of Hx, then we define an 
access V to object X to be excluded in f3 provided that j3 contains CREATE(T') , and 
also contains an INFORM_COMMIT event for an ancestor of T with no preceding 
REQUEST_COMMIT event for T. Then we define a transaction name T to be a 
local orphan in f3 provided that either an INFORM_ABORT event occurs in /3 for 
some ancestor of T, or there is some excluded access to X that is locally visible to 
T. 

We define another binary relation, local-timestamp((l), on accesses to X. Namely, 
(T,T f ) G local-timestamp(/3) if and only if T and T are distinct accesses to X, U 
and U* are sibling transactions that are ancestors of T and T", respectively, (3 con- 
tains an INFORM-COMMIT_AT(X)OF(^jo) event, and f3 contains an INFORM- 
_COMMIT_AT(X)OF([/',p') event, where p < p'. Notice the difference between this 
order and the order local-pseudotime-order(P) defined in [2], where the order was 
based on the timestamps of the accesses, rather than on the timestamps of the sibling 
ancestors of the accesses. 

Before giving our definition of local hybrid atomicity, one additional technical 
notion is needed. Namely, define a sequence £ of operations of X to be transaction- 
respecting provided that for every transaction name T, all the operations for descen- 
dants of T appear consecutively in £. Notice that if (3 is a hybrid behavior, T is a 
transaction name that is not an orphan in /?, it! = completion^) , and X is an object 
name, then view(j3,T,R,X) is perform^) where £ is transaction-respecting. Thus 
by only considering transaction-respecting orderings in the definition of local- views 
below, rather than all orderings consistent with local information, as we did in [5], 
we ensure that the concept of local hybrid atomicity is a closer approximation to the 
concept of hybrid atomicity. Thus, a wider class of correct algorithms can be verified 
using the definitions of this section than would have been the case if the definition 
of local-views did not include the restriction to transaction-respecting orderings. In 
particular, the algorithm that we present in Section 3 can be proved to be local 
hybrid atomic using the definition as given in this section. 

Suppose that /? is a finite hybrid object well-formed sequence of external actions 
of H x and T is a transaction name. Let local-views(/3,T) be the set of sequences 



defined as follows. Let Z be the set of operations occurring in /? whose transactions 
are locally visible at X to T in /?. Then the elements of local- vi ew s{fi ,T) are the 
sequences of the form perform^), where £ is a transaction-respecting total ordering 
of Z in an order consistent with both the partial orders local- completion(/3) and 
local-timestamp(fi) on the transaction components. 

We say that hybrid object automaton Hx for object name X is locally hybrid 
atomic if whenever /? is a finite hybrid object well-formed behavior of Hx, and T is 
a transaction name that is not a local orphan at X in /?, then every sequence that 
is an element of the set local-view$(fi , T) is a finite behavior of Sx- The definitions 
have been chosen so that local hybrid atomicity is a sufficient condition for hybrid 
atomicity. The proof of this fact is analogous to that of Theorem 54 of [5] and 
Theorem 8 of [2]. The main new point to note is the following. In order to show 
that view(serial(/3) y T, R, X) = perform^) is an element of local-views(/3j\Hx ,T), 
it must be shown not only that £ is consistent with the local- completion order as 
before, but also that it is consistent with the local-timestamp order and that it is 
transaction-respecting. 



3 Dependency-Based Hybrid Locking 

This section presents an algorithm, that is a natural generalization to nested trans- 
action systems of that given in [8]. It is based on a serial dependency relation. The 
intuition underlying this is that two operations of a particular serial object should be 
related whenever the possibility of the second occurring is influenced by the presence 
or absence of the first. However, there are many subleties, and the precise definition 
that we give (taken from [2]) is chosen to be what is needed in the algorithm (both in 
that earlier paper and this one). We need a preliminary definition: Let R be a binary 
relation on operations of serial object Sx , and £ a sequence of operations of Sx and 
rj is a subsequence of £, then say that 77 is ^-closed in £ provided that whenever r) 
contains an operation (T, f), it also contains all preceding operations (T",t/) of £ 
such that ((T',i/),(T, v)) G R. Now, we say that R is a serial dependency relation 
for Sx provided that the following holds. Whenever £ is a finite sequence of opera- 
tions of Sx (no two of which involve the same access) such that for each (T, v) in £ 
there is an /^-closed subsequence 77 of £ where 77 contains (T, v) and perform(r)) is a 
behavior of Sx, then perform^) is a behavior of Sx - 

The algorithm is described as a hybrid object automaton in a hybrid system. For 
each object name X and binary relation C between operations of X, we describe a 
hybrid object automaton Dx(C) (a dependency object). In fact, a sufficient condition 
for Dx(C) to be locally hybrid atomic is that C be a symmetric serial dependency 
relation. 

The algorithm is closely related to the commutativity-based locking algorithm 
Lx of Section 8 of [5]. The main difference is that the intentions of concurrent trans- 
actions are not applied to the base state in the order in which INFORM-COMMIT 
events arrive, but rather in the order given by timestamps. Thus when the object 
learns of the commit of a subtransaction, the intentions will be transferred to the 
parent, but rather than being appended at the end of the parent's previous inten- 
tions, they may be inserted into the sequence in an earlier place. To reflect this 



behavior in the automaton, we no longer keep the intentions list explicitly; instead, 
we keep a set of descendant accesses (in the state component intset), and keep track 
of the timestamps provided by the system (in the component time). The intentions 
sequence is then obtained as a derived variable whose value is computed from these 
components. As in commutativity-based locking, the response to an access is con- 
strained so that the resulting operation can be performed by the serial object from 
a state resulting from executing the intentions sequences of the access's ancestors. 

The other change from Lx is in the condition under which an access is enabled. 
The condition here is that there is no other access that is not locally visible to it and 
is related to it by C, whereas in Lx the enabling condition is that no other access 
that is not locally visible to it doesn't commute forward with it. The reason that we 
need C to be a symmetric serial dependency relation is that if an access T completes 
when another access X" has occurred but is not locally visible to T, then the object 
does not yet have sufficient information to know whether T or T" will be ordered 
first by the completion order. Since the return value of T is computed using only 
the intentions list of ancestors of T, this return value is computed without using T'\ 
therefore, the object must be sure that even if T" commits and is serialized before 
T, the return value is not inappropriate. That is, the operation of T should not be 
affected by V . Also, it is possible that T will be serialized before T', so the object 
must ensure that T does not make the previously-given response to T* inappropriate. 
That is, T" should not be affected by T. The definition of serial dependency relation 
expresses exactly this connection. 

The state components of Dx(C) are s. created, s. commit- requested, s.intset, and 
s.time. Here, s. created and s.commit-requested are sets of transactions, all initially 
empty. Also s.intset is a total function from transactions to sets of operations, ini- 
tially mapping every transaction to the empty set 0, and s.time is a partial function 
from transactions to timestamps, initially everywhere undefined. 

We would like to define 5 the derived variable totai(T), which serves the same 
purpose here as in Lx, that is, it is a sequence of operations of Sx that when per- 
formed gives the effective state produced by a transaction T. We define s. intentions, 
a mapping from transaction names to sequences of operations, so that the operations 
in s.intentions(T) are exactly those in s.intset(T), and the order in which these op- 
erations occur is such that (T', v l ) precedes (T", v") if s.time{U f ) and s.time(U u ) are 
both defined and s.time(U f ) < s.time{U"), where U f and U n are the sibling trans- 
actions that are ancestors of V and T", respectively. Now, we let s.total(T) be the 
sequence of operations defined recursively as follows: s.total(To) = s.intentions(T ), 
and s.total(T) — s .total(parent(T))s .intentions (T) for T ^ Tq. 

The transition relation of Dx(C) is as follows. 



5 the following definition is meaningful in any state that is reachable by hybrid object 
well-formed executions of Dx{C). However, it is not meaningful in an arbitrary state. 



CREATE(T) 
Effect: 

s. created = s* .created U {T} 

INFORM_COMMIT^VT(X)OF(T, p) 

Effect: 

s.intset(T) =0 
s .intset(parent(T)) 

= s 1 \intset(parent(T)) U s'.intset(T) 
s.intset{U) 

= s'.intset(U) for U ^ T, parent(T) 
s.time(T) = p 

INFORM^VBORT_AT(X)OF(T) 

Effect: 

s.intset{U) — 0, 

U € descendants{T) 
s.intset(U) = s , .intset(U) y 

U £ descendants(T) 



REQUEST_COMMIT(7» 

Precondition: 

T € s' .created — s f .commit- requested 
fl U t T', v' such that 

((T,v) t (r,v'))€C, 

(T',t/) es'.intset(U), 

U £ ancestors(T) 
perform(s'.total(T)(T t v)) 

is a behavior of Sx 
Effect: 

s.commit-requested = 

a'.commtf-re^ues^erfU {T} 
«.inteet(r) = {(!>)} 
s.intset(U) = *'.intoei(£0 for 17 ^ T 



The following result is proved just like Proposition 67 of [5]. 



Proposition 2. If C is a symmetric serial dependency relation then Dx(C) is lo- 
cally hybrid atomic. 



From this the correctness of the algorithm follows. An immediate consequence 
is that if 5 is a hybrid system in which each hybrid object is of the form Dx(C), 
where C is a symmetric serial dependency relation, then every finite behavior of S 
is serially correct for all non-orphan transaction names. 



Example: Dependency-Based Locking For a FIFO Queue Object Consider 
a system in which an object Sx represents a FIFO queue. Sx has an associated do- 
main of values, V, from which the entries are taken. Sx also has an associated 
function kind : accesses(X) — ► {"insert" , "delete"}, and an associated function 
data : {T € accesses(X) : kind(T) — "insert"} — ► V. The set of possible return 
values for each access T where kind(T) — "delete" is X>, while an access T where 
kind(T) = "insert" has return value "OK". The state of Sx consists of four com- 
ponents: active (either "nil", or the name of an access to X), queue (an array of 
elements of V indexed by the positive integers), front (a positive integer) and back 
(another positive integer). The start state so has sq. active = "niV\ SQ.back = 1, and 
SQ.front = 1 (sq. queue may be arbitrary). The transition relation is as follows: 



CREATE(T) REQUEST_COMMIT(7», 

Effect: for kind(T) - "delete" 

3. active — T Precondition: 

s' . active = T 
REQUEST_COMMIT(7>), s'.back > s'. front 

for kind(T) = "insert" s' .queue[s' .front] = v 

Precondition: Effect: 

s*. active = T s. active = "nil" 

v = "OK" s.front = s'. front -f 1 

Effect: 

s. active = "nil" 

s.queue[s'.back] = data(T) 

s.back = s'.back + 1 



Notice how the delete activity is blocked if the queue is empty (indicated by the 
condition s' .front = s f .back). 

When we use the set of positive integers as timestamps, we can construct the hy- 
brid object automaton Dx(C) where C contains all pairs of operations ((T, v), (T", v')) 
where T±T and either kind(T) = "delete" or JhW(r') = "delete" (or both). C is 
in fact a symmetric, serial dependency relation, so (by the following results) Dx(C) 
is hybrid atomic. 

Suppose Ti, T 2 , T3 and T 4 are accesses to X, with kind(T x ) = fczW(r 2 ) - 
insert, kind(T 3 ) = kind(T 4 ) = de/efe, data{Ti) = 6 and data(T 2 ) = 3. The following 
sequence /? is a schedule of Dx(C). 

CREATE(Ti) 
CREATE(T 2 ) 
CREATE (T 3 ) 
CREATE(T 4 ) 
REQUEST_COMMIT(T 2 , "OK") 
REQUEST-COMMITtTV'Otf") 
INFORM-COMMIT^VT(X)OF(Ti , 2) 

Notice that this schedule involves concurrent insertions into the queue, since the 
response to T\ occurs before the fate of T 2 is known. Since insert operations do not 
commute, /? is not a schedule of the object Lx formed when the commutativity- 
based locking algorithm of [5] is used. This shows that the algorithm presented here 
allows concurrency not available to Lx- 

The schedule j3 can leave Dx(C) in state s where s. created = {Ti,T 2 ,T 3 ,T4}, 
s.commit-requested = {T 2 , Ti}, s.inisei(T ) = {(T u "OK")}, s.intset(T 2 ) = {(T 2 , "OK")}, 
and s.time(Ti) - 2. The derived variable s.total(T 3 ) is just the sequence of a single 
operation (T u "OK"). 

In the state s there is no value v for which either action REQUEST_COMMIT(T 3 ,u) 
or REQUEST_COMMIT(T 4 ,v) is enabled, because of the operation (T 2 , "OK") in 
s.intset(T 2 ). In essence, a delete access can't proceed at this point because the value 
to be returned ought to be 6 if T 2 has a timestamp after that for 7\ or if T 2 aborts, 
but if T 2 commits before 7\, then the delete should return the value 3. 



4 Conclusion 

We have defined an appropriate structure for nested transaction systems based on 
hybrid atomicity, in which each transaction is given a timestamp that indicates 
the order (relative to its siblings) of committing. We have defined hybrid atomicity 
and shown that it was a local atomicity property, so that if each object is separately 
verified to be hybrid atomic, the whole system's correctness follows. We have defined 
local hybrid atomicity and shown that it is a sufficient condition for hybrid atomicity, 
and finally we presented and verified an algorithm that generalizes one of Herlihy 
and Weihl in the unnested case. 

There are several directions in which this work can be extended. One is to find 
and verify further algorithms that provide hybrid atomicity for particular datatypes. 
These might keep information in more compact forms, rather than as sets of oper- 
ations as used in Dx(C). Another is to consider the possibility that timestamps 
do not give exactly the order of completion, but rather another order consistent 
with Lamport causality between siblings. Both the modular atomic property and 
the algorithm should carry over to this situation. 
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A Review of Background 

In this appendix, we summarize the main concepts from our earlier work that are 
used in this paper. Complete details can be found in [5] and [6]. 

All components in our systems, transactions, objects and schedulers, will be 
modelled by I/O automata [11]. An I/O automaton A has a set of states, some 
of which are designated as initial states. Usually a state is given as an assignment 
of values to a collection of named typed variables. The automaton has actions, 
divided into input actions, output actions and internal actions. We refer to both 
input and output actions as external actions. The input actions model actions that 
are triggered by the environment of the automaton, while the output actions model 
the actions that are triggered by the automaton itself and are potentially observable 
by the environment, and internal actions model changes of state that are not directly 
detected by the environment. An automaton has a transition relation, which is a set 
of triples of the form (s f , tt, s), where s' and s are states, and iz is an action. Such a 
triple means that in state $', the automaton can atomically do action tt and change 
to state s. A behavior of an automaton is a sequence of external actions, generated 
as the automaton starts from an initial state and moves from one state to another by 
allowed transitions (note that any tranition involving an internal action may occur 
without being seen in the behavior). 

We describe systems as consisting of interacting components, each of which is 
an I/O automaton. It is convenient and natural to view systems as I/O automata, 
also. Thus, we define a composition operation for I/O automata, to yield a new I/O 
automaton. If (3 is a sequence of actions of a system with component A, then we 
denote by (3\A the subsequence of (3 containing all the actions of A. The definitions 
are chosen so that if /? is a behavior of the system then f3\A is a behavior of A. 

Serial systems, which consist of transaction automata and serial object automata 
communicating with a serial scheduler automaton, are used to characterize the cor- 



rectness of a transaction-processing system. Transaction automata represent code 
written by application programmers in a suitable programming language. Serial ob- 
ject automata serve as specifications for permissible behavior of data objects in the 
absence of concurrency. They describe the responses the objects should make to ar- 
bitrary sequences of operation invocations, assuming that later invocations wait for 
responses to previous invocations. The serial scheduler handles the communication 
among the transactions and serial objects, and thereby controls the order in which 
the transactions can take steps. It ensures that no two sibling transactions are ac- 
tive concurrently — that is, it runs each set of sibling transactions serially. The serial 
scheduler is also responsible for deciding if a transaction commits or aborts. The 
serial scheduler can permit a transaction to abort only if its parent has requested 
its creation, but it has not actually been created. Thus, in a serial system, all sets of 
sibling transactions are run serially, and in such a way that no aborted transaction 
ever performs any steps. We are not proposing serial systems as interesting imple- 
mentations; rather, we use them exclusively as specifications for correct behavior of 
other, more interesting systems. 

We represent the pattern of transaction nesting by a set T of transaction names, 
organized into a tree by the mapping parent, with To as the root. The leaves of 
this tree are called accesses. The accesses are partitioned so that each element of the 
partition contains the accesses to a particular object. If T is a transaction name that 
is an access to the object name X and v is a value, we say that the pair (T, v) is an 
operation of X. The tree structure can be thought of as a predefined naming scheme 
for all possible transactions that might ever be invoked. In any particular execution, 
however, only some of these transactions will actually take steps. We imagine that 
the tree structure is known in advance by all components of a system. The tree will, 
in general, be infinite and have infinite branching. 

The classical transactions of concurrency control theory (without nesting) appear 
in our model as the children of T , which models the environment in which the rest 
of the transaction system runs. It has actions that describe the invocation and return 
of the classical transactions. The only transactions that actually access data are the 
leaves of the transaction tree. The internal nodes of the tree model transactions 
whose function is to create and manage subtransactions, but not to access data 
directly. 

A serial system is the composition of a set of I/O automata. This set contains 
a transaction automaton for each non-access node of the transaction tree, a serial 
object automaton for each object name, and a serial scheduler. The interface to each 
of these automata is described next. 

A non-access transaction T is modelled as a transaction automaton At, an 
I/O automaton. The CREATE input action "wakes up" the transaction. Each 
REQUEST_CREATE output action is a request by T to create a particular child 
transaction. Each REPORT-COMMIT input action reports to T the successful 
completion of one of its children, and returns a value recording the results of that 
child's execution. Each REPORT-ABORT input action reports to T the unsuccess- 
ful completion of one of its children, without returning any other information. The 
REQUEST_COMMIT action is an announcement by T that it has finished its work, 
and includes a value recording the results of that work. We leave the executions of 
particular transaction automata largely unconstrained; the choice of which children 



to create and what value to return will depend on the particular implementation. 

We model the serial specification of an object X (describing its activity in the 
absence of concurrency and failures) by a serial object automaton Sx • Recall that 
transaction automata are associated with non-access transactions only, and that 
access transactions model abstract operations on shared data objects. We associate 
a single I/O automaton with each object name. The external actions for each object 
are just the CREATE and REQUEST-COMMIT actions for all the corresponding 
access transactions. Although we give these actions the same kinds of names as 
the actions of non-access transactions, it is helpful to think of the actions of access 
transactions in other terms also: a CREATE corresponds to an invocation of an 
operation on the object, while a REQUEST_COMMIT corresponds to a response 
by the object to an invocation. A useful notation for operation (T, v) of an object 
X is that perform(T,v) denotes CREATE(T) REQUEST_COMMIT(7». This 
definition is extended to sequences of operations. 

The third kind of component in a serial system is the serial scheduler. The trans- 
actions and serial objects are allowed to be any I/O automata whose actions and 
behavior satisfy simple restrictions. The serial scheduler, however, is a fully specified 
automaton. It runs transactions according to a depth-first traversal of the transaction 
tree. The serial scheduler can choose nondeterministically to abort any transaction 
whose parent has requested its creation, as long as the transaction has not actually 
been created. Each child of T whose creation is requested must be either aborted 
or run to commitment with no siblings overlapping its execution, before T can com- 
mit. The result of a transaction can be reported to its parent at any time after 
the commit or abort has occurred. The REQUEST_CREATE and REQUEST- 
.COMMIT inputs are intended to be identified with the corresponding outputs 
of transaction and serial object automata, and correspondingly for the CREATE, 
REPORT_COMMIT and REPORT_ABORT output actions. The COMMIT(T) 
and ABORT(T) output actions are called completion actions for T; they mark the 
point in time where the decision on the fate of T is irrevocable. 

The discussion in this paper assumes an arbitrary but fixed serial system, with 
At as the non-access transaction automata, and Sx as the serial object automata. 
We use the term serial behaviors for the system's behaviors. We give the name serial 
actions to the external actions of the serial system. 

If /? is a sequence 6 of actions, T a transaction name and X an object name, we de- 
fine P\T to be the subsequence of /? consisting of the following actions: CREATE(T) , 
REQUEST.CREATE(T'), REPORT _COMMIT(T>'), REPORT^VBORT(T'), 
or REQUEST-COMMIT (T», where V is a child of T; and we define (3\X to 
be the subsequence of consisting of the actions CREATE(T) or REQUEST- 
_COMMIT(7» where T is an access to X. We define serial{j3) to be the subse- 
quence of /? consisting of serial actions. 

If /? is a sequence of actions and T is a transaction name, we say T is an orphan 
in /? if there is an ABORT(*7) action in /? for some ancestor U of T. We say that 
T is live in f3 if /? contains a CREATE(T) event but does not contain a completion 
event for T. 



6 We make these definitions for arbitrary sequences of actions, because we will also use 
them for behaviors of systems other than the serial system. 



We use the serial system to specify the correctness condition that we expect 
other, more efficient systems to satisfy. We say that a sequence /3 of actions is 
serially correct for transaction name T provided that there is some serial behavior 
7 such that 0\T = j\T. 

We believe that serial correctness is a natural notion of correctness that corre- 
sponds precisely to the intuition of how nested transaction systems ought to behave. 
Serial correctness for To of all behaviors of a system guarantees that the external 
world will encounter only situations that can arise in serial executions. 

We outline a method for proving that a concurrency control algorithm guarantees 
serial correctness. These ideas give formal structure to the simple intuition that a 
behavior of the system will be serially correct so long as there is a way to order the 
transactions so that when the operations of each object are arranged in that order, 
the result is legal for the serial specification of that object's type. In this paper 
we use a particular choice of serialization order, in which a transaction is serialized 
ahead of those of its siblings that complete after it does. If j3 is a sequence of actions, 
then define compleiion(f3) to be the binary relation on transaction names containing 
(T, V) if and only if T and V are siblings and either there are completion events for 
both T and T" in f3 and a completion event for T precedes a completion event for 
7 1 ', or else there is a completion event for T in /?, but there is no completion event 
for T in /?. 

We must introduce some technical definitions. First, we define when one transac- 
tion is "visible" to another. This captures a conservative approximation to the con- 
ditions under which the activity of the first can influence the second. Let (3 be any 
sequence of actions. If T and T" are transaction names, we say that T" is visible to T in 
if there is a COMMIT(£/) action in /? for every U in ancestors (T f )- ancestors (T). 

We say that an operation (T, v) occurs in a sequence j3 of actions if a REQUEST- 
_COMMIT(7» action occurs in f3. 

Finally we can define the sequence of actions considered in the hypothesis of The- 
orem 3. Suppose f3 is a sequence of actions, T a transaction name, R = completion ((3) 
and X an object name. Let £ be the sequence consisting of those operations occurring 
in f3 whose transaction components are accesses to X and that are visible to T in /?, 
ordered so that (T' ? v') precedes (T", v") if (U*, U") G R, where U' is an ancestor of 
T' t U" is an ancestor of T", and U' is a sibling of U" . Define view(f3, T, R, X) to be 
perform^). 

The following result expresses the fundamental proof technique we use. It is 
proved as Proposition 46 of [5]. The term "simple behavior" is formally defined in [5]; 
informally, it refers to any sequence of actions that does not violate obvious causality 
principles (for example, by creating a transaction that was never requested). The 
concept is sufficiently general that this result can be applied to all behaviors of the 
hybrid system considered in this paper. 

Theorem 3. Let (3 be a finite simple behavior, T a transaction name such thai T is 
not an orphan in ft, and let R = completion(f3) . Suppose that for each object name 
X, view(/3,T,R,X) is a finite behavior of Sx - Then (3 is serially correct for T. 
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